Much of this document is written as though LogDoor is only processing one input log file at a time. This section describes LogDoor's ability to process multiple input log files concurrently, and how that ability can be used to provide detailed site information.
Prior to LogDoor 2.0, LogDoor's focus was to provide the Webmaster with overall information on access to their server on a site-by-site basis, and to create raw log files for each root-level site on their server. It was intended that the Webmaster would provide the raw log files to the site owners, and those owners would then be able to further process those log files as desired. LogDoor 2.0, however, contains a number of features which allow LogDoor itself to perform much of that processing, enabling the Webmaster to obtain and provide detailed, real-time information for sites at any level in their server's hierarchy.
A LogDoor task for a server as a whole (the default) contains detailed access information for sites and files at the root of that server, but not for sites or folders contained within those root-level sites (subsites). In Figure 1 below, Company X has a site represented by a folder named companyX, at the Web server's root. Folder companyX contains another folder named productA, representing a site for one of their products. A LogDoor task using the server's log file as input would contain data for site companyX as a whole, showing total hits, visits, bytes and errors, but there would be no access information about subsite productA or other items within the Company X site.
Figure 1. Subsite Example
Detailed subsite information can be generated in one of two ways: subsite processing and AppleScripts.
LogDoor's Overall summary reports provide details of accesses made to sites and files at the task's root level. Ordinarily, a task's root is the same as the Web server's root. By using LogDoor's "virtual root" feature to change a task's root, and by changing that task's input file, LogDoor's display and reporting functionality can be applied to sites (that is, folders) at any level within a Web server's hierarchy.
To process a subsite, you need to accomplish the following:
You can do this manually, as described above, or do everything with one command. In the status window select the site you wish to be the root site for the new task (companyX in the example). From the Task menu select Items and then "Create Task for Site Item...". You are given the options of overriding the default name of the task and where to save it. When you click OK, a task is created with its root set to ":companyX:" and companyX's log file as an input log file. The new task will inherit the original task's settings for automatic report writing, as specified in the Scheduling dialog, but not for auto-starting on task open.
Once you have created a new task for subsite processing (a "sub-task"), you can set any processing, scheduling or output options you desire for that task, just as with the main task (the "Create Task for Site Item" command will carry the main task's options over as defaults). When the sub-task is run, LogDoor can process it concurrently with other tasks. Its status window and summary reports will reflect accesses only within the site's folder. In the example, productA will appear as a site in that task's status window and summary reports. In addition, a log file will be produced for productA. This procedure can be extended as deeply as needed into a site's subfolders, depending on available memory and CPU.
NOTE: It is not strictly necessary for a task for a subsite (a subtask) to use as its input file the log file for the particular site. The original log file, for the original site (often the log file for the server as a whole), could be used instead. However, since the original log file will contain access information about a large number of sites, most of which will need to be ignored by the subtask, it will always be much more efficient to use the log file for the particular site in question if that log file is available.
In many cases the above detailed site processing options will be sufficient to provide the desired level of detail about accesses to sites, subsites and files on a server. However the amount of reporting data made available through WebSTAR-formatted log files is very large and can theoretically be processed in a nearly-unlimited number of ways. Any particular site may desire its data to be processed in a particular fashion. For this reason, LogDoor makes the raw log file for a particular site available. The site owner can download their log file and process it in any way desired. In many situations, however, it may be more practical to process that log file on the server itself and just have the site owner download the desired report.
As described in a previous section, a reporting AppleScript can be invoked periodically for each site desired within a particular task. Among other possibilities, that AppleScript can invoke a log analysis postprocessor, such as ServerStat, to perform the desired analysis. The AppleScript would pass the following information to the log postprocessor:
The postprocessor would create the desired report and place it at the indicated location. The site owner could then access the report over the Web and obtain the desired information.
An example AppleScript which performs this type of advanced analysis
using ServerStat is included with LogDoor.
Back to Table of Contents
Back to Summary Reports
Forward to HomeDoor-specific Processing